1. Field
The disclosed embodiments relate to techniques for managing access to resources. More specifically, the disclosed embodiments relate to techniques for managing access to resource versions in shared computing environments.
2. Related Art
Service-oriented architectures (SOAs) utilize multiple self-contained, reusable services to implement the functionality of large and/or complex applications. For example, a large enterprise system and/or website may include hundreds of services, each provided by a distinct piece of software that performs one or more specific tasks for users of the enterprise system and/or website. During use of a SOA-based application, multiple service calls may be made to services in the application. Within the application, services may use well-defined interfaces and/or data formats to communicate with one another and interoperate. The interfaces and/or data formats may abstract away from the underlying implementations of the services and allow services in the same application to utilize different development technologies and/or platforms. For example, services in the same SOA-based application may be developed using different programming languages and/or execute within different execution environments and/or platforms.
During development or testing of a newer version of a service in a SOA implementation, a developer may deploy the newer version of the service on his/her local machine. Other services on which the service depends may also be deployed on the same local machine to enable communication among the services and testing of the service's functionality. Alternatively, the other services may run in a remote staging environment along with an older (e.g., current) version of the service, and the newer version may be tested by generating requests that are redirected from the older version in the staging environment to the newer version executing on the local machine. Dependencies of the newer version may be satisfied by sending requests to other services in the staging environment. In other words, the newer version on the local machine may be substituted for the older version in the staging environment to test the newer version and offload resource usage by other services from the local machine to the staging environment.
However, deployment of test services on local machines that are external to the execution environments of other services in the same SOA implementation may be associated with a number of complexities and/or drawbacks. First, the physical distance between a local machine and a remote execution environment may increase the latency associated with servicing requests from the local machine and result in timeouts. Second, differences in network settings and/or configurations (e.g., firewalls, Virtual Private Networks (VPNs), wireless networks, etc.) between the local machine and remote execution environment may produce network errors during communication between test services on the local machine and services in the remote execution environment. Third, rerouting of requests from services in the remote execution environment to test services on the local machine may be performed by maintaining a mapping of the services on the remote execution environment to test versions of the services on the local machine and propagating the mapping to the services. Such dynamic updating and propagation of the mapping within the remote execution environment may significantly increase the complexity of the SOA implementation, while misconfiguration of the mapping may cause routing errors in the SOA implementation. Finally, deployment of a service to a local machine may be associated with increased security risk because the service cannot be effectively monitored and/or audited using security mechanisms available in the remote execution environment.
Consequently, development of services in SOAs may be facilitated by mechanisms for simplifying the use of development and/or test services with existing services in the SOAs.
In the figures, like reference numerals refer to the same figure elements.